Unpack the gradle distributions without restoring timestamps from the archive in an attempt to fix #210#369
Unpack the gradle distributions without restoring timestamps from the archive in an attempt to fix #210#369
Conversation
… archive Fixes #210 The timestamp in the archive may be far in the past (reproducible archives - https://docs.gradle.org/9.2.0/userguide/working_with_files.html#sec:reproducible_archives) and may cause problems in situations where 32bit applications interact with the filesystem. As the timestampp is entirely irrelevant, resetting it to the uncompress time avoids the problem. Signed-off-by: Christoph Obexer <cobexer@gradle.com>
cobexer
force-pushed
the
cobexer/updates
branch
from
59a5bbf to
f07b8ad
Compare
| \ | ||
| && echo "Installing Gradle" \ | ||
| && unzip gradle.zip \ | ||
| && unzip -DD gradle.zip \ |
| \ | ||
| && echo "Installing Gradle" \ | ||
| && unzip gradle.zip \ | ||
| && unzip -DD gradle.zip \ |
There was a problem hiding this comment.
❌ This doesn't fix #210 for me when doing docker build --platform linux/arm/v7 . on this Dockerfile. It's generally not about the timestamp, but about the inode returned by the underlying fs, so I don't think this will do much. The timestamps should still be within 32-bit range.
There was a problem hiding this comment.
I can reproduce this failure as well. That means that the other side effect of the touch of /opt/gradle/lib/ is also/more relevant: the inode being copied up into the upper layer of the overlayfs.
I don't think it would make sense to trigger that on purpose.
|
Moved unrelated changes to #372 |
cobexer
force-pushed
the
cobexer/updates
branch
from
f07b8ad to
79268ac
Compare
cobexer
changed the title
|
Since the problem can still be reproduced with "normal" timestamps we conclude that the source of the issue is the directory inode number, and working around that is not something we want to do. Instead, JDKs should resolve that issue. |
4 participants
Cannot locate JAR for module 'ant'on old Java versions (<23) #210